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Airspace 

Classification 18,000' MSL 




Nontowered 
airport with 
no instrument 
approach 


x?< x?< 


Source: Pilot's Handbook of Aeronautical Knowledge, FAA 
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NOTIONAL SCENARIO 




• Analogy: Regardless of whether a car is self-driving or not, an infrastructure and 
system governing operations that includes roads, traffic lights, and rules are needed 


• Missing: Infrastructure to support operations at lower altitudes 


UTM Technical Challenge Description 


Safely enable UAS operations at lower altitudes 

• Current state of the art: Commercial low altitude UAS operations 
are not allowed and demand is likely to grow considerably 

• Solution: Develop a new system called UAS Traffic Management 
that will support- airspace design, geo-fencing, wind/weather 
integration, separation management, and contingency operations 

• Main activities: UTM builds’ design and development, FAAand 
stakeholder coordination, collaborative testing, 

• Benefit: Being able to safely allow UAS at low altitudes 

• Stakeholders: National and international interest - service 
providers, UAS operators, system integrators, UAS manufacturers, 
FAA, FAA test sites, etc. 

• Product: UTM requirements and prototype cloud-based system 
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UTM: UAS Operator Needs 



• Access to Airspace 

- Is airspace open or closed now and in the near-future? 

- In which airspace they can operate; which airspace should they avoid? 

• Traffic Awareness 

- Will there be anyone else in the vicinity? 

- UAS, gliders, helicopters, and general aviation 

• Changes to Trajectory to optimize business 

- What should I do if I need to change my trajectory? 

• Contingencies Management 

- How to manage a contingency? 

• Airspace Manager 

- Who should operate the airspace and how? 
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UTM: Role of Airspace Manager 



• Airspace Design and Dynamic Adjustments 

- Corridors design, altitude/direction allocation, geo-fencing definition, 
community concerns, airspace blockage due to severe weather/wind 
prediction or contingencies 

- Delegated airspace as the first possibility 

• Support fleet operations as well as singular operators (analogy - 
airline operations center and flight service stations) 

• Overall schedule driven system to ensure strategic de-conflictions 
(initially, overtime much more dynamic and agile) 

• Management by exception 

- Operations stay within geo-fenced areas and do not interrupt other 
classes of airspace operations in the beginning stages 

- Supports contingency management 
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UAS User Access to UTM 



• Cloud-based: user accesses through internet 

• Generates and files a nominal trajectory 

• Adjusts trajectory in case of other congestion or pre-occupied 
airspace 

• Verifies for fixed, human-made, or terrain avoidance 

• Verifies for usable airspace and any airspace restrictions 

• Verifies for wind/weather forecast and associated airspace 
constraints 


• Monitors trajectory progress and adjust trajectory, if needed 
(contingency could be someone else’s) 

• Supports contingency - rescue 

• Allocated airspace changes dynamically as needs change 
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UTM Design Functionality 



• For safe UAS operations, UTM should support: 

- Airspace management and geo-fencing (reduce risk of 
accidents, impact to other operations, and community concerns) 

- Weather and severe wind integration (avoid severe weather 
areas based on prediction) 

- Allow only authenticated operations (avoid unauthorized 
airspace use) 

- Predict and manage congestion (mission safety) 

- Terrain and man-made objects database and avoidance 

- Maintain safe separation (mission safety and assurance of other 
assets) 
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Request for Information 

Federal Business Opportunities 



• Request of information was solicited through Federal Business 
Operations focused on partnerships and collaborative tests 

• Over 95 respondents in the UAS community indicated interest to 
collaborate with NASA on the development of UTM 

• Currently sorting through responses and identifying what various 
partners can provide 

• Universities, private industry, other government agencies all provided 
responses to the RFI 

• No exchange of funds, collaboration to accelerate development, testing, 
and in-field operations 

• Novel partnerships: Vehicle manufacturers, test sites, DOI, insurance 
companies, academia, communication, surveillance, system 
integrators, etc. 
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Collaboration with FAA, NOAA, and DOI 



• Formed a research transition team between FAA and NASA that is 
focused on UTM (as part of overall autonomy thrust) 

• Held kick-off meeting to discuss UTM vision 

• Conducted FAA, NASA, local UAS industry meeting to understand 
the needs of the UAS industry and FAA 

- Operational tempo (frequency, density, locations, etc) 

• NASA will be UTM technology developer and conduct collaborative 
tests 

• NOAA: Weather service (wind, severe weather) at low altitudes 

• DOI: UTM capability to manage national parks (largest landowner) 
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Student and Faculty Projects 



• University of Massachusetts 

• Duke University 

• Stanford University 

• University of California, Berkeley 

• Others in planning 

- University of Maryland 

- Rutgers University 

- Boise State University 

- Cal Poly 
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International Interests 


• Korea 

• France (Exploring collaboration on similar activity called Mach7) 

• Poland 

• Japan 


Concept of Operations 



• Developing ConOps document 

• Formalizes the concepts discussed in this presentation 

• Seek comments from industry and government partners in the 
coming months 

• ConOps being developed in parallel with requirements 
documentation and demonstration planning. All are converging 
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Requirements 



• Developing the functional requirements for the system as a whole 
broken down on a “per build” basis. 

• Build 1 : 

- UTM securely communicates with external clients. 

- UTM manages UTM airspaces/geo-fences/restricted areas 

- UTM provides non-towered-like services to UAS 

- UTM provides some level of separation services 

- UTM supports replay of a UTM scenario 

- All UAS adhere to their accepted plans (no off-nominal scenarios) 

• Build 2, 3, 4 each add further services and capabilities. 
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Schedule 



• UTM research and development driven by various “Builds” 

• Each Build adds more services and capabilities 


1 

A 


Build 1 




Build 2 




Build 3 




Build 4 




Demo: Aug 2015 


• Demo: Oct 2016 


• Demo: Jan 2017 


• Demo: Mar 2018 

Geo-fencing and 


• Dynamic airspace 


• Trajectory 


• Large scale 

airspace design 


adjustments 


conformance 


contingency 

Open/close 


• Demand/Capacity 


monitoring 


management 

airspace for wx 


imbalance 


• Web portal for 



Basic procedural 


• Initial contingency 


UTM access 



separation 


management 


Heterogeneous 



Simple scheduling 




operations 



Initial constraint 







database 
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Near-term UTM Builds Evolution 



UTM Build 

Capability Goal 

UTM1 

Mostly show information that will affect the UAS trajectories 

• Geo-fencing and airspace design 

• Open and close airspace decision based on the weather/wind 
forecast 

• Altitude Rules of the road for procedural separation 

• Basic scheduling of vehicle trajectories 

• Terrain/man-made objects database to verify obstruction-free 
initial trajectory 

UTM2 

Make dynamic adjustments and contingency management 

• All functionality from build 1 

• Dynamically adjust availability of airspace 

• Demand/capacity imbalance prediction and adjustments to 
scheduling of UAS where the expected demand very high 

• Management of contingencies - lost link, inconsistent link, 
vehicle failure 
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Near-term UTM Builds Evolution 



UTM Build 

Capability Goal 

UTM3 

Manage separation/collision by vehicle and/or ground-based 

capabilities 

• All functionality from build 2 

• Active monitoring of the trajectory conformance inside geo- 
fenced area and any dynamic adjustments 

• UTM web interface, which could be accessible by all other 
operators (e.g., helicopter, general aviation, etc.) 

• Management of separation of heterogeneous mix (e.g., 
prediction and management of conflicts based on 
predetermined separation standard) 

UTM4 

Manage large-scale contingencies 

• All functionality of build 3 

• Management of large-scale contingencies such as “all-land” 
scenario 
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Build 1 Demonstration 


• Identifying partners 

- Vehicles and auto pilot systems 

- Operators services 

- Logistics, insurance, and etc. 

- Academic institutions 

- Communication and Surveillance 

• Plan to run the demo in simulation in early 2015 

• Plan to run the initial tests with NASA and/or partner vehicles in Spring 201 5 

• Full demo at end of summer 2015 with participation of RFI partners 

• Test site being determined 

- NASA’s Crow Landing is likely, provides us greatest control 

- All UAS Test sites are interested 

- External partners also have sites identified that we may leverage 


Build 1 Demo Description 



• Two vehicles separated procedurally by staying in their own planned 
space 

• Surveillance provided by operators: they report their own position 

• UTM system accepts/rejects plans as they are submitted free of 
constraint intersection or not 

• For testing/safety/post-operations analysis, maintain active 
surveillance of UAS 

• Test various operation plan combinations of: planned, rejected, 
early ending, etc. 
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Example Interface 



Start Date Time 


2014-08-20 

▼ 


▼ 



End Date Time 


2014-08-20 

▼ 


▼ 



Load Feature 


Load Feature Information 


lion 


H Lion 876 -Test Operator [2014- 
08-20T1 8:00:00Z - 2014-08- 
20T1950.-00Z] 



^ Linda 


Oliyehui 


Lincoln 


Roseville 


Operator: Test Operator 
Primary Contact: Jimmy 
Aircraft: Lion 876 

Effective Time Begin 2014-08-20T18:00:00Z 
Effective Time End: 2014-08-20T19:30:OOZ 
Description: 

Agriculture observations 




% "Srv ; . 

/ ' a 




Knights^ 

Vj Landing n v 


Antelope 
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Geo-fenced Areas 




UAS area of operations geo-fence 

Operators may request an area of 
operation. If granted, a geo-fence 
is implemented wherein other 
requests that intersect spatially 
and temporally with the operation 
could be denied. 





“■ W 


UAS trajectory geo-fence 


Operators may request specific 
trajectory for an operation. If 
granted, a geo-fence based on the 
vehicles operating parameters will 
be created to keep other vehicles 
within the UTM system from 
intersecting. 



Airspace constraint geo-fence 

Airspace that is off limits to UAS 
operations (airports, TFRs, etc.) 
will have a geo-fence prohibiting 
acceptance of plans that intersect. 
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Flight Plan States 



Closed 
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Client services: software perspective 


Developed initial 
prototype 
software to handle 
client requests. 

Clients can submit 
a flight plan and 
track updates via 
our API. 

Clients can also 
request data with 
the system related 
to flights and 
constraints 


o 

o 

cd 

o 


0 

■ 

o 


1 . Flight Request via WFS-T 


2. Synchronous response with id info 


3a. Asynchronous response with 
' approvaTinTo via http(s) ' 

3b. Asynchronous updates on 
' approval status via http(s) 

1 . Flight state data submitted via WFS-T 


Client 


2. Synchronous ‘ACK’ response 


Client 


1 . WFS request for UTM data 


2. Synchronous response with data 


Client 


1 . Subscribe to websocket data feed 


2. Continuous asynchronous data via 
“websocket 


Client 


Flight 

Submission, 

Flight 

Approval, 

Flight 

Decision 

Status 

Updates 

Flight Position 
updates 


UTM Data 
Requests 


Publication 

Services 
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UTM Hierarchical Topology 


Portable and Persistent System Can Co-exist 





Client development 



• Several initial testing partners for interface and integration 

• Drone Deploy and 3D Robotics have each developed client software 
to interact with our prototype 

• In discussions with other partners for various system-integration 
one-off tests 

• Initial architecture has been well-received by industry partners 
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Example: 3D Robotics Integration 


■^Droneshare X (•) common-Mission Planner x Q] NASA UTM: Home x 

C A G www.droneshare.com/mission/32498 © Q 0 ^ r *'* Q E 


■" Apps Cl NASA Cj Literature Cl] Programming Q OR i Latex £] Air Traffic Cj Conferences Android Fun Stuff [^Business » 


SDbobotics Droneshare 


X 

r 

nasa_uas ▼ 

Map Missions About 




Software integration with 
existing UAS consumer tools 
already in development 



3D Robotics demonstrated 
sharing data from their web- 
based platform to our 
prototype UTM system 


Berkeley, 94710, California, L 

Fri May 09 2014 - 6:02:21 PM 



common-Mission Plannc 


; Q NASA UTM: Home 


x @ UTM: UAS Traffic Manage 


GAS https://tmiserver.arc.nasa.g 0 v/UTMWebApp/plar 1 # ^ @J Q § ^ ^ #$• Q 

■■■Apps Q NASA Q Literature Q Programming LJ OR Q Latex Cj Air Traffic Q Conferences Cj Android CJ Fun Stuff LJ Business C Shopping 


UAS Traffic Management 


Welcome, user3dr 


Map Satellite 


View Planned Operations View/A ► 


Displaying features between: 

201 4-04-01 T00:00:00 ~ 2014-05- 
13T00:37:12 


Operator: 10 

Primary Contact: nasa_uas@droneshare 
Aircraft: quadcopter 

Effective Time Begin 201 4-05-1 0T01 :02:21 Z 
Effective Time End: 201 4-05-1 0T01:09:20Z 
Flight Comments: 

null 


Black Hawk 2-9 
[2014-08- 

18T16:00:00Z~ 2014-08 
1 8T21 :OO:0OZ] 


Black Hawk 2-9 
[2014-08- 

18T16:O0:OOZ~ 2014-08 
1 8T21 :00:OOZ] 


Black Hawk 2-9 
[2014-11- 

11T16:00:00Z~ 2014-11 
1 2T21 :00:00Z] 


lris+-10 [2014-11- |*| 

10T22:23:02Z~ 

2014-1 1-1 0T22:28:02Z1 


/ quadcopter-1 0 [2014- * 

05-10T01:02:21Z ~ 


20 1 4-05-1 0T0 1 :09 :20Z] 


quadcopter-1 0 [2014- * j 

05-10T01:02:21Z~ 


201 4-05-1 0T01:09:20Z] 


/ quadcopter-1 0 [2014- * 

05-10T01:02:21Z~ 


Map dataS20l 4 Google Imagery ©201 4. DigitalGlobe.U.S. Geological Survey TermsofUse [ Reportamap 



FY15 Resources (Minimum) 


Category 

Total 

Budget 

$5M 

Procurement (testing, logistics, etc.) 

$2M 

FTE and WYEs ■ 
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Note: Budget based on continuing resolution and may adjust 





Next steps 



• Internal system integration tests in preparation of Build 1 Demo, 
Spring 2015 

• Build 1 Demonstration, summer 2015 

• Complete plan and schedule for future builds 

• Strengthen external partnerships to leverage others’ capabilities and 
receive buy-in of concept from non-government stakeholders 

• Communicate with FAA to ensure solid transfer of technology 
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Summary 



• Near-term goal is to safely enable initial low-altitude operations 
within 1 -5 years 

• Longer-term goal is to accommodate increased demand in a cost 
efficient, sustainable manner 

• Strong support for UTM system research and development 

• Collaboration and partnerships for development, testing, and 
transfer of UTM to enable low altitude operations 

• Major gathering around UTM late Spring 

• Step towards higher levels of autonomy 


Pari mal.H. Kopardekar@nasa.gov 
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BACKUP SLIDES 


UTM - One Design Option 











Example Research and Development Needs 


• Minimum UTM system design and requirements 

• Minimum vertical and horizontal separation minima among UAS and other 
operations (gliders, general aviation, helicopters) 

- Static or dynamic 

- Analytical, Monte Carlo or other types of modeling 

• Tracking accuracy and separation minima trade-off 

- Oceanic separation vs en route aircraft separation 

• Trajectory models for better prediction of different UAS 

• Vehicles and wind/weather related considerations - modeling and prediction 
of winds, eddies, and weather at low altitudes 

- May need to enhance weather prediction capabilities 

• Classification of UAS - bird strike example 
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Example Research and Development Needs 


• Contingency procedures: large-scale and individual vehicle 

• Sense and avoid - many products, research activities, and NASA 
UAS challenge 

• Human computer interface design options for UTM manager 

• Human computer interaction options for UAS ground control station 

- How many UAS can a ground control station operator manage 

• Type of UAS and minimum autonomy capabilities 

- Humans can’t operate two rotor failure mode for a multi-rotor vehicle 

• Last/first 50 feet operations landing and safety 

- Various sensor pack and networked options for all weight classes 

• Vehicle risk category 

• Minimum equipage requirements 
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Consideration of Business Models 



• Single service provider for the entire nation such as a government 
entity 

• Single service provider for the entire nation provided by a non- 
government entity (for-profit, or not-for-profit entity) 

• Multiple service providers by regional areas where UTM service 
could be provided by state/local government entities 

- Need to be connected and compatible 

• Multiple service providers by regional areas where UTM service 
could be provided by non-government entities 

- Need to be connected and compatible 

• Regulator has a key role in certifying UTM system and operations 
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Example Student Projects 

• Overall UTM design 

• UTM interface 

• Ground control station interface for multiple vehicle control 

• Separation minima analysis (beyond well clear) 

• Trajectory definition of UAS 

• Wind/weather as related to geo-fencing 

• Noise impact modeling 

• Highways in the sky design (rules of the road) 

• UAS trainer - who is qualified to operate? How quickly you can train? 

• Wireless infrastructure (e.g., CDMA, LTE, etc.) 

• Affordable and light weight sensors for sense and avoid 

• Requirements on UAS - communication, latency, lost communication 
energy depletion, etc. - Minimum 

• Last/first 50 feet technology options (sensors, architecture, human- 
autonomy role, manual input, auto abort, etc.) 

• Business case for private industry 


Types of UTM 



• Portable UTM System: Set up, operate, and move 

- Support humanitarian, agricultural and other applications and be able to 
move from one location to another 

• Persistent UTM System: Sustained, real-time, and continuous 
operations 

- Denali National Park 

- Between mega-cities 

- Urban areas 

• Number of alternative options to design, architect, and operate UTM 

- All ideas are welcome 
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UAS User Access to UTM 



• Cloud-based: user accesses through internet 

• Generates and files a nominal trajectory 

• Adjusts trajectory in case of other congestion or pre-occupied 
airspace 

• Verifies for fixed, human-made, or terrain avoidance 

• Verifies for usable airspace and any airspace restrictions 

• Verifies for wind/weather forecast and associated airspace 
constraints 


• Monitors trajectory progress and adjust trajectory, if needed 
(contingency could be someone else’s) 

• Supports contingency - rescue 

• Allocated airspace changes dynamically as needs change 
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UTM System Requirements 


• Authentication 

- Similar to vehicle identification number, approved applications only 

• Airspace design, adjustments, and geo-fencing 

- Corridors, rules of the road, altitude for direction, areas to avoid 

• Communication, Navigation, and Surveillance 

- Needed to manage congestion, separation, performance characteristics, 
and monitoring conformance inside geo-fenced areas 

• Separation management and sense and avoid 

- Many efforts underway - ground-based and UAS based - need to 
leverage 

• Weather integration 

- Wind and weather detection and prediction for safe operations 


UTM System Requirements 


• Contingency Management 

- Lost link scenario, rogue operations, crossing over geo-fenced areas 

- Potential “9-11” all-land-immediately scenario 

• UTM Overall Design 

- Enable safe operations initially and subsequently scalability and 
expected massive growth in demand and applications 

- As minimalistic as possible and maintain affordability 

• Congestion Prediction 

- Anticipated events - by scheduling, reservations, etc. 

• Data Collection 

- Performance monitoring, airspace monitoring, etc. 

• Safety of Last 50 feet descent operation 

- In presence of moving or fixed objects, people, etc. 


Data Flows 



PostGIS 


Proposed 

Flight 

Table 


Flight 

Table 


2. Geoserver writes data 


3a. Success indicated 
from 


DB to Geoserver 

* 

3b. INSERT to DB 


TRIGGERS call to 



notifier. 


5b. Handler approves/ 
denies flight request, 
removes from proposed 
table, writes to flight table 




^1. Flight Request via WFS-T 

Geoserve 

r 


4a. WFS-T “success” sent to client 


Proposal 

Notifier 


4b. Notifier assigns a handler to 
determine approval status 


Proposal 

Handler 


6b. Handler sends approval 
status via HTTP POST to 
client-supplied URL 
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NOTE: The “Proposal Handler” 
will have access to other data 
sources and fancy algorithms to 
make a decision. That is not 
illustrated here. 
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UTM Client Interface 





